\section{Development Process}
After the design of the program had been finalized, the implementation began. The implementation was split into two parts which would be worked on side by side: one part was the graphical part, implementing the user interface, and the other part was the programming of the audio effects and filters. However, the group encountered some problems when trying to implement the effects and filters. Initially, the latest stable version of Minim was used, but after some time, it was found to be inadequate with what was needed. Therefore, a non-stable beta version of Minim was chosen, since it allowed for what is called \textit{UGens}. Unfortunately, it took more time than expected starting all over with the beta version, but it was necessary to do, since the previous system did not work as intended. 

UGens allows for what is called \textit{patching} in Minim, which is the possibility of passing an outgoing signal from either a song, an oscillator or another filter/effect, into another filter/effect by writing \textit{source.patch(destination)}. If a signal needs to be sent through multiple effects/filters, this can be achieved by appending \textit{.patch(destination2)}.

To get the program working, some kind of system was needed to keep track of which effects were added to, or removed from, the signal. This was done by building the system around an array list that would hold all the effects, so they were easy to access. When the user then added or removed an effect, the array list would be updated. Then everything would be patched again so that the signal would go through the effects in the right order. This was tested with a simple feedforward filter, a multiplier, which worked fine.

Due to the lack of documentation of the Minim library, a lot of problems occurred with understanding how the UGens worked and how to go about implementing the filters correctly, especially when it came to unpatching and repatching everything again. This meant that a lot of trial and error, which took a substantial amount of time. If a better documented library had been used, the development process might have gone faster and more smoothly.

Another problem with the program was that a user is supposed to be able to add as many instances of a filters as he wanted. However, this turned out not to be feasible, as the Java language doesn't support object creation and instantiation during runtime, meaning that all objects has to be defined in the code beforehand. The only way to achieve this would be using \textit{reflection} \cite{reflection}, which seemed outside the scope of this project. Therefore a user could only add as many filters as there were defined in the code, but as a proof of concept this was found to be good enough.

At the time when Minim was chosen, it seemed like a good library to use. However, as the project went on and the group gained more experience in working with audio, it was realized that Minim lacked a lot of basic functionality, examples and documentation. This in turn made the development process more cumbersome and slower than expected.

One thing that the group realized too late was the fact that the development of Minim seemed to be on a halt. Although a small group of people are still working on it, the last major update to the library was uploaded in 2010. Initially, this did not seem as a problem, but the group gradually discovered that the Minim library maybe wasn't the optimal solution for a  project like this.

Because of this, and due to a lack of time, it was decided to downscale the program, so that the user would only be able to add a single instance of each filter to the signal. At this point though, the development was so delayed, partially due to the problems in the beginning as well as the missing documentation, that it would not be possible to get close to having a working prototype with all the different effects, as originally planned. It was chosen to cancel development of most of the effects and try to implement only three of them instead. However, these were not a part of the Minim library and therefore they had to be written as UGens from scratch, meaning that it had to be understood exactly how UGens worked. Information on UGens had to be gathered from reading the source code, as documentation on the UGens was scarce and inadequate. 

In the end, there simply wasn't time to develop a working prototype. The graphical user interface was implemented (using ControlP5) relatively quickly, but the core of the program, the audio effects and filtering, was not. The system for controlling the filters was working with feedforward filters, but without any other filters, the program ended up being only a skeleton on which features, if more time was available, could have been built upon and expanded.

After getting as far as it was possible with the time given, the product, or rather the proposed functionality of the program, had to be tested.

\subsection{Approach to the Test}
The functionality was simply not good enough for the purpose of a test. Since this project is based on a set of hypotheses that need to be approved or rejected, there had to be made some decisions quickly.

In Medialogy, a full implementation of a prototype is not required. Obviously this would be optimal, but fortunately there are other ways to test a prototype. In the second semester, the group learned about a special tool that can be utilized for testing a product, even if that specific product has yet to be fully implemented. This method is called \textit{the Wizard of Oz test}. It was decided to use this approach, instead of trying to finish the program itself. This method will be described in section \ref{wizardTest}. A compromise had to be made, and since the graphical part of the program was working, it was decided to use this when testing. Even though it had no proper functionality, it would be possible to mimic the various audio effects by having a separate program alongside doing this. The music tool called \textit{Reason} \cite{reasonWeb} was chosen and would be used for doing the audio processing such as changing the audio with effects and filters. However, the graphical part of the group's program would still be used as an interface between the test participant and the music tool. Figure \ref{fig:wizardIllustration} illustrates this concept where the group's program acts a link between the test participant and the program that provides the audio effects.

\begin{figure}[htbp]
\centering
\includegraphics[width=0.7\textwidth]{images/Test/wizard_illustration}
\caption{It was chosen to bring in a third-party program to provide the actual functionality for the test.}
\label{fig:wizardIllustration}
\end{figure}